Entities on a computer network such as computers, computers users, and groups of users use network identity data about each other to perform standard network activities. Computer networks typically provide this data through a data server called a directory server. A directory server maintains a database of records that contain identity data about network entities: a user record with a user's name, password, access permissions, and contact information, for example, or a computer record with a computer's Internet Protocol (“IP”) address and name. Network entities send requests for information to a directory server, which responds with the requested information. Requesting entities are called directory clients.
The computer industry has established various standards to ensure conformity and interoperability between computers on a network, and between networks of computers. One of the most widely-used standards for dealing with identity data is the Lightweight Directory Access Protocol (“LDAP”). The basic LDAP protocol is defined in a group of Internet Engineering Task Force (“IETF”) Request for Comments (“RFC”) documents; various aspects of the current version of the protocol (version 3) are described in RFCs listed in the “LDAP Technical Specification Road Map” (RFC4510, published June 2006). The databases reachable through LDAP may contain any sort of data, but most commonly contain identity, contact and authorization information for people, computers and organizations.
LDAP presents a hierarchical view of the data in a database. Records are presented as a tree of entries, each identified by a Distinguished Name (“DN”) and each containing one or more attributes. Attributes consist of an attribute description (an attribute type with zero or more options) and one or more values. For example, an LDAP directory entry might have a “postalAddress” attribute, and its value might be a text string that can be used to send physical correspondence to the subject of the record. An entry generally has a parent or “superior” entry, and may have one or more child or “inferior” entries. Note that the data in the database need not be stored in this hierarchical structure; an LDAP server need only present the impression of such a structure to its clients.
An LDAP server responds to commands from an LDAP client. For example, a client may create a new entry, delete an entry, rename an entry, modify an entry, or (most commonly) retrieve the attributes in an entry. An LDAP client may submit a “search” command seeking a record of a particular type that matches (or contains) certain attribute-value pairs. The LDAP server searches through its hierarchy and may return the requested data if it can be found.
The types of records an LDAP directory server can store and retrieve are defined by an implicit or explicit schema of the server. The schema defines the attributes that may (or must) be present within each record type and the permissible relationships among record types. The types defined by a database schema are called classes. Classes may also have hierarchical interrelationships, so that (for example) a class that contains information about a user of a Unix or Unix-like computer may be subclass (a child or derived class) of a class that contains information about a user of any sort of computer. A database's schema provides a framework within which the database's records fit. The schema governs permissible contents of a data record and relationships between the records. For example, a schema may require that every record that identifies a person include a Social Security number or that every record having an Internet Protocol (“IP”) address be associated with exactly one computer.
An LDAP directory schema describes a class's characteristics with respect to related classes. A class generally inherits characteristics from one parent class and may also inherit from one or more auxiliary classes. A class frequently defines additional new characteristics to supplement its inherited characteristics. A class that inherits characteristics from a parent class is called a child class of that parent class.
An LDAP server creates a new record by instantiating a class. That is, it creates a record whose attributes and relationships conform to the definitions and requirements of the class. Such a record is said to be of the class's type. A client requesting identity data from an LDAP server may specify a record type to search for. If the client asks for a record type that does not exist in the schema, the client's request will fail. It is important that an LDAP server's schema contain classes for the types of records that LDAP clients will request.
The RFC 2307 standard published by the Internet Engineering Task Force (“IETF”) in March, 1988, helps to ensure interoperability among LDAP servers and their clients. It defines classes that must be present within a 2307-compliant LDAP server's schema. One of these classes is called “posixAccount”, and is typically used as an auxiliary class when preparing a database schema containing standard classes for user records (a similar class, “posixGroup”, is used for user group records). That is, the schema uses posixAccount as an auxiliary class to define classes that are instantiated to create user records in the directory server. Such records can be located in a search for posixAccount-type records, and contain posixAccount fields or attributes.
An RFC2307-compliant client can obtain user and group records from a 2307-compliant server by requesting posixAccount- or posixGroup-type records that exist in that server: user records, for example, or group records. Because those records are instantiated from a class that uses posixAccount as an auxiliary class, the client is guaranteed to find them when asking for posixAccount records in that branch.
LDAP servers, such as the widely-deployed Active Directory® (“AD”) server by Microsoft Corporation, usually come with a default schema that can contain the records and support the operations needed for a basic computer network. For more complex networks, a network administrator may need to modify the default schema or even create a new schema. This is a disfavored option, however, because schema modification or replacement cannot be undone, is often disruptive to ongoing network operations, and requires high administrative privileges. Unfortunately, the alternative in many cases is to make extensive changes elsewhere in the complex network, or to abandon the attempt to consolidate identity data for the network within one LDAP server.
New approaches that permit identity data for complex networks to be maintained by an LDAP server, using the server's default schema, may be of value.